Fixes #62281

Problem

JSDoc @type completion does not work for inline JSDoc comments on function parameters. There are two different problems at play in this issue:

Inline JSDoc on function parameter

/** @import * as t from "./types" */

function foo(/** @type {t./*cursor*/} */ param) {}

Inline JSDoc comment with no parameter name

/** @import * as t from "./types" */

function foo(/** @type {t./*cursor*/} */) {}

In neither of those cases there are completion suggestions at the /*cursor*/ location.

Cause

In file src/services/completions.ts

Inline JSDoc on function parameter

In this case the check if (insideComment) evaluates to false because insideComment is undefined. This, despite the fact that getTokenAtPosition returns a valid token inside the JSDoc tree.
More specifically:

Since insideComment is falsy, the if (insideComment) block is skipped entirely and insideJsDocTagTypeExpression is never set to true, so no JSDoc type completions are provided.

Inline JSDoc comment with no parameter name

Even after the issue above is fixed, there's a second problem:

Both of these cases fail to generate completion, however, they fail for two fundamentally different reasons:

Solution

Inline JSDoc on function parameter

For this case we just need to add an else clause to handle the case where insideComment is falsy, but the current token is inside a JSDoc comment.

if (insideComment) {
    // ... existing JSDoc completion logic (unchanged for this issue) L3324
}
else {
    // NEW: Handle inline JSDoc on function parameters.
    // For these, isInComment returns undefined but we can still
    // find a JSDocTag ancestor from the currentToken.
    const tag = getJsDocTagAtPosition(currentToken, position);
    ...
}

Inline JSDoc comment with no parameter name

This one is trickier. Since hasDocComment is false, we can't use the normal JSDoc APIs, instead we manually extract the comment text and parse it. This introduces a potential performance hit, but tests indicate it is not too severe.

if (tag) {
    // ... existing JSDoc completion logic (unchanged for this issue) L3358
}
else {
    // NEW: Handle orphaned JSDoc comments (no param name)
    const commentText = sourceFile.text.substring(insideComment.pos, insideComment.end);
    ...
}

Testing performance

I ran tests for four different scenarios:

• orphaned-qualified: function foo(/** @type {t.} */) {} - WORST CASE (triggers full orphaned handling + namespace search)
• orphaned-simple: function foo(/** @type {str} */) {} - orphaned JSDoc, but no namespace search needed
• named-param: function foo(/** @type {t.} */ param) {} - used added else clause to handle JSDoc with named param
• no-jsdoc: function foo(param) {} - baseline, no JSDoc processing

Some things to highlight

1. main is faster, but that is because code gives up early and does not complete
2. Even in the worst case scenario, the added time to provide completions remains under ms range, so users are not going to experience lag
3. The no-jsdoc baseline is added for reference, to show overhead of the processing in general (dashed gray line)
4. Solid lines indicate quantile 50 (median), shaded area indicates quantiles 25-75 for 1000 runs of each scenario

Test Plan

1. Added unit tests to cover both scenarios
2. Verified performance
3. Manual testing in VS Code to verify completions show up as expected

// types.ts [example types for testing]
export interface MyType {
  name: string;
  value: number;
}

export interface OtherType {
  id: number;
}

export namespace Nested {
  export interface DeepType {
    deep: string;
  }
}